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Abstract 

Specifying and implementing flexible human-computer dialogs, such as those used in ATMs, 
airport and train kiosks, and apps for smart phones and similar devices, is challenging because 
of the numerous and varied directions in which each user might steer a dialog, all of which 
must be captured in a specification and implementation of it. The purpose of this research is 
to improve dialog specification and implementation. To do so we enriched a notation based on 
concepts from programming languages, including currying and partial evaluation, for specifying a 
variety of unsolicited reporting, mixed-initiative dialogs in a concise representation which serves 
as a plan for implementing the dialog. We also built a dialog mining system which extracts 
specifications in this notation from dialog requirements. To demonstrate that the structure of a 
dialog specification in this notation provides a design for its implementation, we built a system 
which automatically generates an implementation (called a stager) for it given its representation 
in this notation. This resulted in a dialog modeling toolkit which automates the process of 
specifying and implementing dialogs. These results provide a proof of concept and demonstrate 
the promise of studying dialog specification and implementation from a programming languages 
perspective. The ubiquity of dialogs in domains such as banking and travel, education, and 
health care, combined with the increased use of smart phones as personal computing devices 
and the proliferation of apps for them, provide a fertile landscape for the application of these 
results. 



Keywords: currying, human-computer dialogs, mixed-initiative dialogs, mixed-initiative inter- 
action, partial evaluation, program generation, program transformation, Scheme 



1 Introduction 



From automated teller machines (ATMs), airport and train kiosks, apps for smart phones and sim- 
ilar devices to wizards (e.g., Microsoft Word) and intelligent tutoring/training (e.g., SAT, Rosetta 
Stone, military), human-computer dialog^ are woven into the fabric of our daily interactions with 
computer systems. While supporting flexibility in dialog is essential to deliver a natural experience 
to the user, it makes the implementation challenging due to the numerous directions in which a user 
might desire to steer a dialog, all of which must be captured in an implementation. This problem 
is difficult since dialogs range in complexity from those modeled after a simple pre-defined series 
of questions and answers to those which give the user a great deal of control over the direction in 
which to steer the dialog. In this article, we discuss a computational model, based on concepts 
from programming languages, and especially partial evaluation, for specifying and staging dialogs. 
The objective of this work is to enrich and demonstrate the feasibility of an alternate method of 
modeling human-computer dialogs. 

This article is organized as follows. To introduce the reader to the wide range of dialogs possible, 
and provide a better feel for this problem and its difficulty, we first present some illustrative 
examples of dialogs. In this section we simply showcase a variety of dialogs and describe how 
they can be specified using formal notation, rather than discuss their implementation and related 
issues which are covered later. In Section [2] we describe a programming languages notation for 
specifying dialogs. Section [3] demonstrates how dialogs can be staged with partial evaluation, 
while Section U] outlines how to mine dialog specifications in a programming languages notation 
from dialog requirements, and how we automatically generate stagers from those specifications in 
programming languages notation. Section [5] summarizes our contributions and discusses future 
work. 

1.1 Fixed- and Mixed-initiative Dialogs 

Consider a dialog to purchase gasoline using a credit card. The customer must first swipe the 
card, then chose a grade (of octane), and finally indicate whether they desire a receipt. Such a 
dialog is said to be a fixed dialog due to the fixed order of the questions from which the user is not 
permitted to deviate in her responses [1]. An enumerated specification of this dialog is {^credit- 
card grade receipt^}. An enumerated specification is a set of episodes, and an episode is an ordered 
list of questions to be posed and answered from the start of the dialog through dialog completion. 
Intuitively, a specification is a complete set all possible ways to complete a dialog. We can think of 
a dialog specification as a set of totally ordered sets or chains. We use a Hasse diagram, a graphical 
and concise depiction of a partially ordered set, to represent a dialog specification. A relation R 
with the set S over whose Cartesian product R is defined is a partially ordered set (or poset) if R is 
a reflexive, antisymmetric, and transitive relation. This means that some of the elements of S may 
be unordered based on the relation R. On the other hand, a set S* is a totally ordered set according 
to a relation R iff for every two elements (x, y) G S, xRy or yRx. Every totally ordered set is also 
a partially ordered set, but the reverse is not necessarily true. 

Fig. [1^ illustrates the Hasse diagram for this gas dialog specification. A Hasse diagram is read 
bottom-up. Here, the set S of the poset is the set of the questions posed in the dialog and R of the 
poset is the 'must be answered before' relation denoted with an upward arrow between the source 
and target of the arrow. 

dialog in this context refers to any series of interactions between a user and a computer system, not necessarily 
through a verbal modality. For instance, a user completing an online mortgage application participates in a human- 
computer dialog. 
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(a) receipt (b) 



(c) dine-in/take-out receipt (d) 



grade 




cream sugar 
(cream sugar) J 
sub-diaiog 1 



size biend cream 
(size cream) (biend cream) 



eggs toast 
(eggs toast) J (size biend) 

sub-diaiog 2 

(size biend cream) 



receipt dine-in/take-out 



(most rigid) fixed diaiogs 



mixed-initiative diaiogs (most tiexibie) 



Figure 1: A spectrum of unsolicited reporting, mixed- initiative dialogs: Hasse diagram representa- 
tions of enumerated dialog specifications spanning from fixed (a) to complete, mixed-initiative (e) 
dialogs. 



Flexible dialogs typically support multiple completion paths. For instance, consider a dialog 
for ordering coffee. The participant must select a size and blend, and indicate whether room for 
cream is desired. Since possible responses to these questions are completely independent of each 
other, the dialog designer may wish to permit the participant to communicate the answers in any 
combinations and in any order. For example, some customers may prefer to use a ^size blend 
creams episode: 

SYSTEM: Please select a size. 
USER: Small. 

SYSTEM: Please select a blend. 
USER: Dark. 

SYSTEM: Please specify whether you want room for cream. 
USER: No. 



while others may use a ^blend cream sizey episode: 

SYSTEM: Please select a size. 
USER: Mild. 

SYSTEM: Okay mild blend. Please select a size. 
USER: With room for cream. 

SYSTEM: Okay with room for cream. Please select a size. 
USER: Large. 



while still other might like to use a ^(size blend) cream)^ episode, where answers to the questions 
enclosed in parentheses must be communicated in a single utterance: 

SYSTEM: Please select a size. 
USER: Small, french roast. 

SYSTEM: Please specify whether you want room for cream. 
USER: No. 



Therefore, to accommodate all possibilities we specify this dialog as: 



{-<(size blend cream);-, 
-< (blend cream) size;-, 
^blend (size cream);-, 
-(blend size cream)-, 
Scream size blend;-}. 



-<(size blend) creamy, 
-<size (blend cream) 
-<size blend cream)—, 
-< blend cream size)—. 



-< cream (size blend))—, 
^(size cream) blend;-, 
-<size cream blend)-, 
-< cream blend size)-. 



Notice that this specification indicates that answers, to the set of questions in the dialog, may 
be communicated in utterances corresponding to all possible set partitions of the set of questions. 
Moreover, all possible permutations of those partitions are specified as well. The Hasse diagram for 
this dialog is given in Fig. [1^. The absence of arrows between the size, blend, cream, (size blend). 
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Table 1: Sample dialogs involving permutations and/or partitions of responses to questions. 



Only a single response 
per utterance 



Multiple responses 
per utterance 



Only one Confirmation dialog boxes 
utterance common in application software 



Online forms with 
multiple fields 



Totally Purchasing gasoline with a 

ordered credit card; buying beverages 
from a vending machine 



Partially 
ordered 



Providing a telephone, 
credit card, or PIN number 
through voice 



ATMs, and airport or train kiosks Ordering a coffee or pizza 



enumerated 
dialog specification 



compressed dialog specification 
in PL notation 



dialog system (stager) 



((size blend cream) 
(size cream blend) 
(blend size cream) 
(blend cream size) 
(cream size blend) 
(cream blend size) 
((cream blend size))) 



PE* 



size blend cream 



Please enter a size. 

> no room for cream 

Okay no room for cream. 
Please enter a size. 

> mild 

Okay mild. Please enter a size. 

> small 



lossless dialog 


automatic generation 


compression/mining algorithm 


of dialog system 


dialog modeling toolkit 





Figure 2: Conceptual overview of our research project. 



(size cream), (blend cream), and (size blend cream) elements indicates that the times at which 
each of those utterances may be communicated are unordered. Notice that the Hasse diagram is 
a compressed (and, thus, optimal) representation capturing the requirements in the specification. 
Moreover, the compression is lossless (i.e., the episodes in the enumerated specification may be 
reconstructed from the diagram). 

Giving the user more flexibility in how to proceed through a dialog increases the number of 
episodes in its enumerated specification. This coffee ordering dialog is a mixed-initiative dialog [1]. 
There are multiple tiers of mixed-initiative interaction. The tier considered in this article is called 
unsolicited reporting — an interaction strategy where, in response to a question, at any point in the 
dialog, the user may provide an unsolicited response to a forthcoming question. 

When all possible permutations (i.e., orders) of all possible partitions (i.e., combinations) of 
responses to questions are supported, we call the dialog a complete, mixed-initiative dialog. Fig. [1] 
represents a space from fixed dialogs to complete, mixed-initiative dialogs, encompassing a wide 
variety of possible unsolicited reporting, mixed-initiative dialogs. Table [T] identifies some practical, 
everyday dialogs which fall into the cross product of permutations and partitions of responses to 
questions. 

Fig. [2] provides an overview of this research project. We start with an enumerated dialog 
specification (i.e., a set of episodes) and mine it for a compressed representation of the dialog 
in a programming languages notation which capture the requirements of the dialog (transition 
from the left to the center of Fig. [2]) — a process we call dialog mining. From that intermediate, 
implementation-neutral representation we automatically generate a dialog stager capable of realiz- 
ing the dialog or, in other words, staging the interaction (transition from the center to the right of 
Fig. ED. 
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1.2 Spectrum of Dialogs 



Fixed and complete, mixed-initiative dialogs each represent an opposite end of this spectrum of 
unsolicited reporting dialogs as shown in Fig. [TJ There are several dialogs between those two ends. 
For instance, consider a specification for an ATM dialog where PIN and amount must be entered 
first and last, respectively, but the transaction type (deposit or withdrawal) and account type 
(checking or savings) can be communicated in any order (see Fig. [TJd): 



{-;PIN transaction account amount;^, ^PIN account transaction amount;^}. 



This dialog contains an embedded, mixed- initiative sub-dialog [T]. 

Alternatively, consider a dialog for ordering lunch where requesting a receipt or indicating 
whether you are dining-in or taking-out can be communicated either first or last, but specification 
of sandwich and beverage must occur in that order: 

{^receipt sandwich beverage dine-in/take-out)", -< dine-in/take-out sandwich beverage receipt^}. 

This dialog contains an embedded, fixed sub-dialog and, unlike the prior examples, cannot be 
captured by a single poset (see Fig. [lb) . 

Lastly, consider a dialog containing two embedded, complete, mixed-initiative sub-dialogs |16J 
(see Fig.IB): 

{-<cream sugar eggs toast)-, -(cream sugar toast eggs^, -<(cream sugar) toast eggs^, 

^(cream sugar) eggs toast;^, ^sugar cream eggs toast)-, ^sugar cream toast eggs)—, 

^oggs toast cream sugar)-, ^eggs toast sugar cream)-, ^toast eggs cream sugar)—, 

-<toast eggs sugar cream)-, -<sugar cream (eggs toast);—, Scream sugar (eggs toast);—, 

-<(cggs toast) (cream sugar);-, -< (cream sugar) (eggs toast);-}. 

Here, the user can specify coffee and breakfast choices in any order, and can specify the sub-parts 
of coffee and breakfast in any order, but cannot mix the atomic responses of the two (i.e., episodes 
such as Scream eggs sugar toast ;^ are not permitted). 

There are two assumptions we make on this spectrum of unsolicited reporting, mixed-initiative 
dialogs in this article: i) each episode in a specification has a consistent length (i.e., number of 
questions) and ii) the permissible responses for each question are completely independent of each 
other (i.e., no response to a question ever precludes a particular response to another question). 



2 Specifying Dialogs in a Programming Languages Notation 

There is a combinatorial explosion in the number of possible dialogs between the fixed and complete, 
mixed-initiative ends of the spectrum in Fig. [T] Specifically, the number of dialogs possible in this 
space is 2l-^'='"»l — 1 = Y^'^Ji''^ ('"^'J.'"'') (i.e., all possible subsets, save for the empty set, of all episodes 
in a complete, mixed-initiative dialog), where T'cmi represents the enumerated specification of a 
complete, mixed-initiative dialog given the number of questions posed in the dialog. In this 
section we bring structure to this space by viewing these dialogs through a programming languages 
lens for insight into staging them. We start by describing how to specify these dialogs using a 
programming languages notation which involves a variety of concepts from programming languages. 
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Table 2: Type signatures of functions in the model demonstrating that partial evaluation ([mix]) 
subsumes the other operators. Assumes a ternary function / : (a x 6 x c) — >• d. 



Concept 


Function 




Type signature 




A-calculus 


/ 


apply : 


(((a X b X 


c) ^- 


X a X b X c) — ^ d 





A(/, X, y, z).f{x^ z) 


c 


curry : 


{{a X b X i 




{a ^ {b ^ {c ^ d))) 




\{f).\{x).\(v).Mz). fix, V, z) 


PFA 




(((a X b X 


c) ^ d) 


X a) — y ((6 X c) — ¥ d) 




X( f. x^.Xdi. z^. f(x^ v. z) 


PFA„ 


papplyn : 


(((a X fe X 


c) d) 


X a) — )> ((b X c) — > d) 





Af f, x^-Xiv, z).f(x,ij, z) 






(((a X fe X 


c) d) 


X a X b) {c d) 


— 


A(/, X, y).\{z).f(x, y, z) 






(((a X fe X 


c) d) 


X a X X c) — !■ ({} — !■ d) 




Hf,x,y,z).\{).f{x,y,z) 


SPE 


smix ; 


(((a X 6 X 


c) cZ) 


X a) — ((fe X c) d) 




Hf, x:).\{y,z).f{x,y,z) 






(({a X 6 X 


c) d) 


X 6) ((a X c) ^ d) 




Hf, 2)./(x,y,^) 






(((a X fe X 


c) d) 


X c) — > ((a X 6) — > d) 




\{f,z).\{x,y).f(x,y,z) 


PE 


mix : 


(((a X fe X 


c) d) 


X a) — !• {{b X c) — > d) 




Hf^ ^)-Hy,z).f{x,y,z) 






(((a X fe X 


c) — > d) 


X fe) — i- ((a X c) — > d) 




Kf, y)-K^,z)-f{x,y,z) 






(((a X fe X 


c) d) 


X c) — >■ ((a X 6) d) 




\{f,z).\{x,y).f{x,y,z) 






(((a X 6 X 


c) d) 


X a X 6) — > (c — > d) 




>>(/, a:, y).A(2:)./(a;,y, 2) 






(((a X b X 


c) d) 


X 6 X c) — s- (a — > d) 










({{a X b X 


c) d) 


X a X c) — i- (6 — > d) 




X{f,x,z).X{y).f{x,y,z) 






(((a X X 


c) -> d) 


X a X X c) — >• ({} — >• d) 




Hf,^,y,z)-H)-f{x,y,z) 



Table 3: Definitions of papply (left), papplyn (center), and smix (right) in Scheme. 

(define papply (define papplyn 

/-, ^/ s ,/ ff ^ ^ (define smix 

(lambda fun are) (lambda fun . ares) s 

^ , ^ ^' ^ , ^ ' (lambda (fun static_arg) 

(lambda x (lambda x ( ' f stat ' c a ))) 

(apply fun (cons arg x))))) (apply fun (append args x))))) (mix un s a ic_argjjj 



2.1 Dialog Types 

In this notation a dialog is specified by an expression of the form where X represents a con- 
cept from programming languages and Q is a list representing the questions in the dialog (being 
specified). The main idea in this notation is that the set of episodes specified by an expression of 
this form correspond to all possible ways that a function parameterized by the questions in the 
denominator can be partially applied, and re-partially applied, and so on, according to the concept 
in the numerator. This notation was introduced in [2] and re- visited in [llj . Here, we enrich it 
with additional language concepts and modify its semantics. 

The concepts from programming languages in this model are interpretation (/), currying (C), 
partial function application (PFA), partial function application n (PFAn), single-argument par- 
tial evaluation (SPE), and partial evaluation (PE). These concepts correspond to higher-order 
functions which each take a function and some subset of its parameters as arguments. The type 
signatures for the functions of this model are given in Table [2j We assume readers are familiar with 
interpretation [3], currying and partial evaluation [7j. Partial function application, papply, 
takes a function and its first argument and returns a function accepting the remainder of the pa- 
rameters. The function papplyn, on the other hand, takes a function / and all of the first n of 
m arguments to / where n ^ m, and returns a function accepting the remainder of the (m — n) 
parameters. Notice that with single-argument partial evaluation, the function may be partially 
evaluated with only one argument at a time. All of these functions except apply return a function. 
Table [3] provides definitions of papply, papplyn, and smix in Scheme. 

These functions are general in that they accept a function of any arity as input. The functions 
curry, papply, papplyn, smix, and mix are closed (i.e., they take a function as input and return 
a function as output). Here, we are interested in a progressive series of applications of each of 
these functions which terminate at a fixpoint. Therefore, we superscript a type X with a where 
applicable, to indicate a progressive series of applications of the corresponding function ending in a 
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Table 4: Specifications of dialogs in programming languages notation (left) and as enumerated 
specifications (right). 





/ 


= 


size 


blend cream 






C 


= 


size 


blend cream 






PFA 


= 


size 


blend cream 






PFA^ 


= 


size 


blend cream 








= 


size 


blend cream 






SPE 




size 


blend cream 






spe' 




size 


blend cream 






PE 




size 


blend cream 






PE* 




size 


blend cream 





{^(size blend cream) 
{^sizc blend crcam^} 
{^sizc (blend cream) 

{^(size blend cream) ^(sizo (blend cream) ^, 
-((size blend) cream;^} 

{^(sizc blend crcam);^, ^sizc (blend crcam);^, 
-<(size blend) cream)-, -<sizc blend cream)-} 

{^sizc (blend cream))-, ^blend (size cream))-, 
-< cream (size blend))-} 

{^size blend cream)-, -(size cream blend!^, 
-< blend size cream)-, — (blend cream size)-, 
-< cream blend size)-, —(cream size blend)-} 

{-((size blend cream))-, -(size (blend cream))-, 
-(blend (size cream))-, -<cream (size blend))-, 
-((size blend) cream;^, —((size cream) blende, 
-((blend cream) size;^} 

{-((size blend cream);-, — ;(size blend) cream)-, 
—(cream (size blend))-, -< (blend cream) size;^, 
-(size (blend cream);^, —((size cream) blend;^, 
-(blend (size cream))-, — ;size blend cream)-, 
-(size cream blend)-, —; blend size cream)-, 
-(blend cream size)-, —(cream blend size)-, 
-(cream size blend)-} 
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Table 5: Association of types of dialogs, along permutations and partitions (of questions) axes, to 
concepts from programming languages. 





Only a single response Multiple responses 




per utterance per utterance 


Only one utterance 


interpretation (/) 


Totally ordered 


currying (C) partial function application n (P_FA*) 


Partially ordered 


single-arg. partial eval. {SPE ) partial eval. (PE*) 



fixpoint. For instance, repeatedly applying papplyn to a ternary function (e.g., (apply (papplyn 
(papplyn f small) mild) no) realizes the episode ^size blend creams in addition to the ^size 
(blend cream) ^(size blend) cream;^, and ^(size blend cream) ;^ episodes which are realized with 
only a single application of papplyn. Note that C = C* (i.e., the function returned from the 
partial application of a curried function is in curried form; there is no need to re-curry it) and 
1 = 1* since apply does not return a function. Therefore, we can superscript PFA, PFAn, SPE, 
and PE with a ★ symbol. 

The right side of Table H] shows enumerated specifications of dialogs for ordering coffee. Each 
dialog also can be specified using one of the dialog types presented here. The left side of Table [H 
shows how those dialogs are specified using this programming languages notation. We associate 
a fixed dialog with currying (C) (second row of Table H]) and a complete, mixed-initiative dialog 
with partial evaluation (PE*) (bottommost row of Table The types (and combinations of 
them) in Table H] help specify dialogs between the fixed and complete, mixed-initiative ends of this 
unsolicited reporting spectrum. Note that the order of the terms in the denominator matters (i.e., 
^ b^)' ^lso> note that when the number of questions posed in a dialog is less than three, 
the /, C, and PFA types specify the same episodes (e.g., ^ = ^ = = {~<a b>-}). Table [5] 
associates types of dialogs, along permutations and partitions (of questions) axes, to some of the 
concepts from programming languages in this model, and helps connect the dialogs in Table [J with 
the concepts used to specify them. The SPE type is introduced below. 

Note that there is always only one episode possible in any dialog specified using only one of 
the /, C, or PFA types. There are always q episodes in any dialog specified using only one of 
the PFAn and SPE types, where q is the number of questions posed in a dialog. The number 
of episodes in any dialog conforming to any of the PFA!^, SPE , PE, and PE* dialog types as a 
function of q is 2'^^^, ql, Ylp=i (p)> ^^"^ Ylp=iP^- ^ '^il^ P)^ respectively. The episodes in any dialog 
specified using only one of the /, C, PFA, PFAn, PFA*n, SPE, SPE', PE, or PE* types are 
related to each other in multiple ways. For instance, by definition of the * symbol here, X C X*, 
where X is any dialog type (e.g., PFA or PE). Other relationships include 

SPE C PE, 
PFAn U SPECPE, 
{{PFA*^- PFAn) U {SPE* - SPE)) n PE = ^, 
PFA C PFAn, 
/ U C U PFA U PFAn = PFA*n, and 
PFA* C PE*. 

Lastly, / U C U PFA U PFAn U PFA* U SPE U SPE' U PE C PE* meaning that the 
PE* type subsumes all others. The implication of this, as we see in the following section, is that 
any dialog conforming to one of these types can be supported through partial evaluation. 
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Table 6: Specifications in programming languages notation of the dialog specifications depicted 
using Hasse diagrams in Fig. [1] as well as an additional dialog specification (see bottommost row). 
Annotations (a)-(e) on the leftmost column of the first five rows help associate these specifications 
to those in Fig. [TJ 



(a) 
(b) 



(e) 



c 

credit-card grade receipt 
C 



PIN 



SPE 



transaction account 



c J 

^ ' receiDt sandwich drink dine-in /take-out 

(d) 



receipt sandwich drink dine-in/take-out dine-in/take-out sandwich drink receipt 

spe' 



PE* PE* 
cream sugar eggs toast 

PE* 
size blend cream 

C II C II C 



(^) „;^„ SPE — U TT— T— gPB— U 



blend SPE cream blend size 

" blend cream cream size 



2.2 Sub-dialogs 

We denote the space of unsolicited reporting, mixed-initiative dialogs shown in Fig. [T] with the 
symbol U. Here X denotes a particular type of dialog (e.g., C or PE*) which specifies a set of 
episodes, while X denotes a class of dialogs (e.g., C or V£*), where a class is defined as a set of 
dialog specifications of type X based on q, the number of questions posed in a dialog. The number 
of dialogs possible in this space is 2l^^*l — 1, and there are 2'^^*l — Aql — q — Q dialog^ in the 
spectrum shown in Fig. [1] which cannot be specified with a single type (e.g. dialogs b, c, and d in 
Fig. [1] and Table [6]). We call the class containing these dialogs A. There are notable observations 
on the space U: a) its classes are totally disjoint, b) the I, SV£, SV£ , V£, and V£* classes always 
contain only one specification independent of q, c) the VJ-A class always contains q specifications 
because there exists one specification per question, where the response to that question is supplied 
first and the responses to all remaining questions arrive next in one utterance, d) the C, VJ-An, and 
VJ-An classes always contain q\ specifications as each contains one specification per each episode 
in a SPE dialog type (in Tableland introduced below), and e) therefore, the number of dialogs 
specifiable with only a single type is 4g! -|-g-|-6. However, this programming languages notation for 
dialog specification is expressive enough to specify the dialogs in the A class because those dialogs 
can be expressed as a union of types (e.g., dialog c in Tabled or ^^-^ U = {^(x y z)>-, ^x 
(y z):^}) or expressed as dialogs involving sub-dialogs through the use of nesting [2] (e.g., dialogs 
b and d in Table [6|), or both (e.g., dialog f in Tabled]). 

In dialogs containing more than one sub-dialog in the denominator, the /, PFAn, PFA^, PE, 
and PE* types are not candidates for the numerator because these types imply multiple responses 
per utterance and it is not possible to complete more than one sub-dialog in a single utterance. 

^For q^3, |A| = \U\ - \1\ - \C\ - \VTA\ - \VTAn\- \PTAl\ - \SP£\ - \V£\ - \V£*\. The cases where g = 1 and 
g = 2 are the only cases where |A| / \U\ - \T\ - \C\ - \VTA\ - \VTA„ \ - \VTA*,\ - \ST£\ - \V£\ - \V£*\. This is 
because when q= 1, the one specification in each of the individual classes is the same in each class. Similarly, when 
q — 2 some specifications are multi-classified. 
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The PFA and SPE types suffice for dialogs with no more than two sub-dialogs (e.g., p^^, 

a b c d 

and pEi'pE* ) because when used as the numerator in an expression whose denominator contains 

a b c d 

more than two terms they also imply multiple responses per utterance. Hence, C is the only type 
which can always contain any number of sub-dialogs in the denominator. However, C cannot be 
used in the numerator of a dialog specification where there are two or more sub-dialogs in the 
denominator which can be completed in any order. Thus, we need a type which restricts utterances 
to one response but also permits all possible completion orders. We call this type SPE , and 
spe' — 

size blend cream 

{^size blend cream!^, ^sizo cream blend)^, ^blend size creamj^, 
^blend cream size!^, Scream blond size^, -;cream size blend;^}. 

Note that Jl* pe* ^ pe*'^pe* pe* , and SPE' C PE*. 

abed cf abed cf 



2.3 Rewrite Rules 

Types / and C are primitive in that any dialog in this space can be specified using only / and 
C. In particular, to specify any dialog in this notation we can simply translate each episode in 
an enumerated specification as a C expression and the entire specification as a union of those C 
expressions. For instance, ^^^-j U U ^^-j = {^x y zy, -<y z xy, -<z x yy}. Furthermore, all 
dialogs specified using this notation can be reduced to a dialog using only the / and C types. For 
example, = -t- = {-<x (y z)y}. Therefore, we can define rewrite rules akin in spirit to those 

in [n]- 

Specifying dialogs in this spectrum (shown in Fig. [1]) with a programming languages notation 
has multiple effects: a) it helps bring structure to the space between the two ends of the spectrum, 
b) it helps us losslessly compress the episodes in an enumerated specification of a dialog without 
enumerating all of the episodes (to capture the possible orders and combinations of responses) 
therein and, therefore, provides a shorthand notation for dialog specification, akin to the Hasse 
diagram method, and c) a dialog specified in this notation provides a design for implementing the 
dialog, as we see below. 

Use of concepts from programming languages, such as interpretation, currying, and partial 
evaluation, to specify dialogs has been established in [TBI El 111]- What we have presented here is 
a modification of the notation from [11]. Specifically, we have added types to enrich the notation 
and re-defined types to more accurately reflect the concepts to which they are associated. 



3 Staging Dialogs by Partial Evaluation 

Since partial evaluation can be used to partially apply a function with respect to any subset its 
parameters (i.e., it supports the partial application of a function with all possible orders and 
combinations of its arguments), we can stage any unsolicited reporting, mixed- initiative dialog in 
this space using only partial evaluation. In other words, partial evaluation is a generalization of 
any dialog type or, alternatively, each dialog type, except PE*, represents a particular type of 
restriction on partial evaluation. 

We use an example to illustrate how dialogs can be staged with partial evaluation. Consider the 
ternary Scheme function f shown in Listing [TJ We call a function such as this, which we partially 
evaluate to stage a dialog, a script. Assume that we wrote this function without the intent of ever 
invoking it, and rather only with the intent of automatically transforming it for effect. This effect 
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Table 7: Staging dialog episodes by partial evaluation, explicitly illustrating the intermediate output 
of each partial evaluation. Dotted boxes reinforce that both series of transformations (top half and 
bottom half) start with the same script. 



Staging the dialog episode ^sizc blend creams = 
by partial evaluation (|mix]). 



c 

size blend cream 



mix 



(lambda (size blend cream) 

(if (member? size <sizes>) 

(if (member? blend <blends>) 
(if (member? cream <cream>) 
(retrieve item)))))) 



size= small 



(lambda (blend cream) 

(if (member? blend <blends>) 
(if (member? cream <cream>) 
(retrieve item))))) 



mix 



(lambda (blend cream) 

(if (member? blend <blends>) 
(if (member? cream <cream>) 
(retrieve item))))) 



blend=mild 



(lambda (cream) 

(if (member? cream <cream>) 
(retrieve item)))) 



mix 



(lambda (cream) 

(if (member? cream <cream>) 
(retrieve item)))) 



cream=no 



(retrieve item) 



Staging the dialog episode ^blcnd size creams = 

by partial evaluation (|mix]). 



c 



blend size cream 



mix 



(lambda (size blend cream) 

(if (member? size <sizes>) 

(if (member? blend <blends>) 
(if (member? cream <cream>) 
(retrieve item)))))) 



blend=dark 



(lambda (size cream) 

(if (member? size <sizes>) 

(if (member? cream <cream>) 
(retrieve item))))) 



mix 



(lambda (size cream) 

(if (member? size <sizes>) 

(if (member? cream <cream>) 
(retrieve item))))) 



size= large 



(lambda (cream) 

(if (member? cream <cream>) 
(retrieve item)))) 



(lambda (cream) 
|mixj (if (member? cream <cream>) 

(retrieve item)))) 



cream=yes 



(retrieve item) 



11 



Table 8: Alternate view of Table [TJ without explicit illustration of the intermediate outputs of each successive partial evaluation. 



Staging the dialog episode -<size blend creams 



c 

size blend cream 



by partial evaluation (|mix]). 



mix 



mix 



mix 



(lambda (size blend cream) 

(if (member? size <sizes>) 

(if (member? blend <blends>) 
(if (member? cream <cream>) 
(retrieve item)))))) 



size=small 



blend=mild 



cream=no 



(retrieve item) 



Staging the dialog episode -<blend size cream> 



C 



blend size cream 



by partial evaluation (|mix]). 



mix 



mix 



mix 



(lambda (size blend cream) 

(if (member? size <sizes>) 

(if (member? blend <blends>) 
(if (member? cream <cream>) 
(retrieve item)))))) 



blend=dark 



size= 



=large 



cream=yes 



(retrieve item) 



Listing 1: Scheme function f we call a script. An expression of the form < . . . > is used to represent 
a list of valid choices (e.g., <sizes> could represent ' (small medium large)). 



(define f 

(lemibda (size blend cream) 

(if (member? size <sizes>) 

(if (member? blend <blends>) 
(if (member? cream <creain>) 
(retrieve item) 
( invalid-response )) 
( invalid-response ) ) 
( invalid-response ) ))) 



Table 9: Staging all episodes possible in a dialog conforming to dialog types using partial evaluation. 
Specifications of dialogs in a programming languages notation (left) staged by partial evaluation 
(|mix]) (right). The use of ellipses in expressions such as size=. . . indicate that the value of the 
parameter can be any valid response. 



|mix] [f , size = . . . , blend = . . . , cream = . . .] 
|mix] [|mix] [|mix] [f , size = ...], blend =...], cream 
|mix][|mix][f, size = . . .], blend = . . ., cream = . . .] 



size 


blend cream 






C 




size 


blend cream 






PFA 




size 


blend cream 






PFA„ 




size 


blend cream 






PFA-„ 




size 


blend cream 





|mix] [f , size = . . . , blend = . . . , cream = ...], 
|mix][|mix][f, size = . . .], blend = . . . , cream = ...], 
|mix][|mix][f, size = . . . , blend = . . .], cream = . . .] 

|mix] [f , size = . . . , blend = . . . , cream = ...], 
|mix][|mix][f, size = . . .], blend = . . . , cream = ...], 
|mix] [|mix] [f , size = . . . , blend = ...], cream = ...], 
|mix] [|mix] [|mix] [f , size = ...], blend = . . .] , cream 
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Table 10: Staging all episodes possible in a dialog conforming to dialog types using partial eval- 
uation. Specifications of dialogs in a programming languages notation (left) staged by partial 
evaluation ([mix]) (right). 



size 


SPE — 
blend cream 


|[mix| 


[[mix] [f, size = ...], cream - 


= . . . , blend 


_ j 








|mix| 


[[mix] [f , blend = ...], size = 


= . . . , cream 


_ j 








[mixj 


[[mix] [f , cream = . . .] , size - 


= . . . , blend 


j 




size 


spe' — 

blend cream 


[mix! 


[[mix] 


[mix] [f, size = . . . 


, cream = . . .], 


blend 








[mix] 


[[mix] 


[mix] [f , size = . . . 


, blend = ...], 


cream 


= '■'■], 






[mix| 


[[mix] 


[mix] [f, blend = . 


■■] 


size = ...], 


cream 


= ...], 






[mix] 


[[mix] 


[mix] [f, blend = . 


■■] 


cream = . . 


.], size 


= ...], 






[mix] 


[[mix] 


[mix] [f , cream = . 


•• 


,size = ...], 


blend 


= ...], 






[mix] 


[[mix] 


[mix] [f , cream = . 


•• 


, blend = . . 


.], size 


= • • •] 


size 


D TP 

rrj — 
blend cream 


[mix] 


[f , size 


= . . . , blend = . . 


, cream = . . .] 










[mix] 


[[mix] [f, size = . . .], cream - 


= . . . , blend 


= . . .] 








[mix] 


[[mix] [f , blend = ...], size = 


= . . . , cream 


= . . .] 








[mix] 


[[mix] [f, cream = . . .], size - 


= . . . , blend 


= • • •] 








[mix] 


[[mix] [f , size = . . . , blend = 


= ...], cream 


= • • •] 








[mix] 


[[mix] [f , size = . . . , cream = 


= . . .], blend 


= . . .] 








[mix] 


[[mix] [f, blend = . . . , cream = . . .], size 






size 


P E* 
blend cream 


[mix] 


[f , size 


blend, cream], 














[mix] 


[[mix] [f , size = •••], blend = 


= . . . , cream 










[mix] 


[[mix] [f, blend = . . . , cream = . . .], size 










[mix] 


[[mix] [f, blend = . . .], cream = . . . , size 










[mix] 


[[mix] [f , cream = . . . , size = 


= . . .], blend 










[mix] 


[[mix] [f , cream = . . .] , size - 


= . . . , blend 










[mix] 


[[mix] [f , size = . . . , blend = 


= . . .], cream 










[mix] 


[[mix] 


[mix] [f , size = ... 


, cream = ...], 


blend 








[mix] 


[[mix] 


[mix] [f, size = . . 


, blend = ...], 


cream 








[mix] 


[[mix] 


[mix] [f, blend = . 


■■] 


size = ...], 


cream 








[mix] 


[[mix] 


[mix] [f, blend = . 


■■] 


cream = . . 


.], size 








[mix] 


[[mix] 


[mix] [f , cream = . 


•• 


,size = ...], 


blend 








[mix] 


[[mix] 


[mix] [f , cream = . 


•• 


, blend = . . 


.], size 
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is staging the interaction of a human-computer dialog. While f is a function, here we only think 
of it as only a malleable and disposable data object. When that input data is expired, the dialog 
is complete. In this model, f is only data. 

The top half of Table [7] demonstrates how the -<size blend creamy episode is staged by this 
process. We use the symbol |mix] from to denote the partial evaluation operation because 
partial evaluation involves a mixture of interpretation and code generation. The [mix] operator 
accepts two arguments: a function (to be partially evaluated) and a static assignment of values 
to a subset its parameters. The semantics of the expression [f][3] in the notation from [7] are 
invoke f on 3 or f(3). Consider a function pow which accepts a base and an exponent (in 
that order) as arguments and returns the base raised to the exponent. The semantics of the 
expression [mix] [pow, exponent = 2] are partially evaluate pow with respect to exponent equal to 
two. This returns pow^^p^j^gj^^^j a squaring function) which accepts only a base. Therefore, 

P°"exponent=2 a complctc evaluation 

[[mix] [pow, exponent = 2]] [3] = [pow] [3, 2] = 9. Given a ternary function f with integer 
parameters x, y, and z: 

fy=2 = [mix][f,y = 2] 

output = [fy=2][l,3] 

[f][l,2,3] = [[mix][f,y = 2]][l,3]. 

In general, 

|[mix][/, input.t^ti^input^y^^^J = lfj[inputstatic, input dynamic]- 

This same function f can be used to realize a completely different episode than the one after 
which it is modeled. The bottom half of Table [7| demonstrates how the ^blend size cream;^ episode 
can be staged by this process, with the same function f . While f reflects only one episode (in this 
case, ^size blend cream;^), by partial evaluating f we can stage the interaction required by 13 
distinct episodes. In general, by partially evaluating a script representing only one episode, we can 
realize |Pcmj| distinct episodes. This 'model one episode, stage multiple' aspect of this approach is 
a significant aspect of this research. 

While Table [7] shows how f is transformed after each progressive partial evaluation in the 
process. Table [8] omits these intermediary outputs and, thus, provides an alternate view of Table [71 
The scripts being partially evaluated in Tables [7] and [8] omit else (exceptional) branches (e.g., 
(invalid-response) in Listing [T]) for purposes of succinct exposition and conservation of space. 
Notice from Table [7] that, at any point in the interaction, a script always explicitly models the 
questions which remain unanswered and, therefore, implicitly models the questions which have 
been answered. As a result, it is always clear what information to prompt for next. In the mixed- 
initiative dialog community, keeping track of what has and has not been communicated is called 
dialog management. 

The right sides of Tables [9] and [10] detail how a dialog specified using only one of each dialog 
type is staged by partial evaluation, which subsumes all of the other types based on the arguments 
with which you partially evaluate f . For instance, PFA^ is achieved by progressively partially 
evaluating f with any prefix of its arguments. Similarly, = -t- = {^x (y z);^} can be staged 

with partial evaluation as |mix][|mix][f,x = ...], y =..., z = .. .]. 

Given Table [71 we see why the enumerated specifications of dialogs on the right side of Table [H 
are associated with the types on the left side of Table HI and how dialogs conforming to those 
specifications can be staged (i.e., realized) in Tables [9l and [TOl Tables [9l and [TOl together naturally 
mirror Table [H 
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Listing 2: Transcript of an interactive session with the dialog miner illustrating how compressed 
specifications in programming languages notation, including specifications a, b, and e in Table O 
are mined from enumerated specifications. 



;; only ouc utterance; interpretation or complete evaluation 

> (mine-expr '(((credit-card grade receipt)))) 
(("I" credit-card grade receipt)) 

; ; example a: a fixed dialog specification ; 

; ; totally— ordered with only a single response per utterance; 

; ; currying 

> (mine-expr '((credit-card grade receipt))) 
(("C" credit-card grade receipt)) 

;; totally ordered with nmltiplc responses per utterance; partial function application n* 

> (mine-expr '((size blend cream) ((size blend) cream) 

(size (blend cream)) ((size blend cream)))) 
(("PFA_n*" size blend cream)) 

; ; partially ordered with only a single response per utterance ; 
; ; single— argument partial evaluation' 

> (mine-expr (permutations '(size blend cream))) 
(("SPE"' size blend cream)) 

example e: a complete, mixed— initiative dialog; 
partially ordered with multiple responses per utterance; 
partial evaluation* 

> (mine-expr (append (permutations '(size blend cream)) 

'(((size blend) cream) 
(cream (size blend)) 
(size (blend cream)) 
((blend cream) size) 
((size cream) blend) 
(blend (size cream)) 
((size blend cream))))) 
(("PE*" blend cream size)) 

; ; example b: a dialog specification containing 

; ; an embedded, complete, mixed— initiative sub— dialog 

> (mine-expr '((PIN account transaction amount) (PIN transaction account amount))) 
(("C" PIN ("SPE'" account transaction) amount)) 



4 Implementing Dialogs with Partial Evaluation 

A specification of a dialog in this programming languages notation provides a plan for the imple- 
mentation of the dialog. In this section we discuss the implementation details of automatically 
generating a dialog system from an enumerated specification of a dialog to be implemented (see 
Fig. [2]). While the details of dialog mining (i.e., extracting a minimal specification in programming 
languages notation from an enumerated dialog specification; see transition from the left to the cen- 
ter of Fig. [2]) are beyond the scope of this paper, and more appropriate for a data mining audience, 
we make some cursory remarks. 

4.1 Dialog Mining 

We designed a recursive, heuristic-based algorithm to address this problem, and implemented it in 
555 lines of Scheme code. Listings [2] and [3] provide a transcript of an interactive session with our 
dialog mining system. The input to the miner is an enumerated dialog specification expressed as a 
list of episodes, where each episode is also expressed as a list (e.g., see lines 24-30 of Listing[2|). The 
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Listing 3: Continuation of transcript of an interactive session with the dialog miner (in Listing [2]) 
ihustrating how compressed specifications in programming languages notation, including specifica- 
tions c and d in Tabled are mined from enumerated specifications. 



; ; example c: a dialog specification containing an embedded, fixed sub— dialog, 
; ; or the union of two fixed dialog specifications 

> (mine-expr '((receipt sandwich beverage dine-in/takeout) 

(dine-in/takeout sandwich beverage receipt))) 
(("C" receipt sandwich beverage dine-in/takeout) 
("C" dine-in/takeout sandwich beverage receipt)) 

; ; example d: a dialog specification containing 

; ; two embedded, complete, mixed— initiative sub— dialogs; 

> (mine-expr '((cream sugar eggs toast) (cream sugar toast eggs) (sugar cream eggs toast) 

(sugar cream toast eggs) (eggs toast sugar cream)(eggs toast cream sugar) 
(eggs toast (cream sugar)) (toast eggs sugar cream) (toast eggs cream sugar) 
(toast eggs (cream sugar)) ((cream sugar) eggs toast) 
((cream sugar) toast eggs) 

(cream sugar (eggs toast)) (sugar cream (eggs toast)) 
((cream sugar) (eggs toast)) 

((eggs toast) (cream sugar)) ((eggs toast) cream sugar) 
((eggs toast) sugar cream))) 
(("SPE"' ("PE*" cream sugar) ("PE*" eggs toast))) 

; ; a dialog specification as the union of three expressions 

> (mine-expr '((size blend cream) (size cream blend) (blend cream size) 

(cream blend size) (blend size cream))) 
(("C" ("SPE"' size blend) cream) 

("C" size cream blend) ("C" ("SPE'" blend cream) size)) 

; ; case demonstrating the incompleteness of heuristic 
; ; output should be (~ ~ SPE'" x ( ' C" y z)) 

> (mine-expr '((x y z) (y z x))) 
(("C" X y z) ("C" y z x)) 
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Listing 4: A stager for complete, mixed-initiative dialogs (i.e., those in the V8* class), simplified 
for purposes of presentation. 



(define stager_pe* 
(lambda (script) 

(if (not (null? script)) 

(let* ((utterance (prompt-f or-input)) 

(static- input (mar shal-utterance-into-a- set -of -parameter /value pairs)) 
(specialized-script (mix script static-input))) 
(stager_pe* specialized-script))))) 



output is a dialog specification in this programming languages notation. The form of the output is a 
list of lists where each list in the output list represents an expression in this programming languages 
notation (see line 31 of Listing [2] and lines 41-42 of Listing [3]). The car of each list within the 
output list is the numerator of the dialog specification in programming languages notation and the 
cdr of it is the denominator. The nesting of each list within the output list reflects the nesting 
in the specification of the dialog in this programming languages notation. For instance, line 36 of 
Listing [2] represents ^ . If the output list contains more than one list (e.g., 

PIN amount 

account transaction 

dialog c in Table [6] whose compressed specification is shown on lines 41-42 of Listing [3]), the union 
of those lists specifies the dialog. The miner was tested in Dr. Racket (v. 5. 1.1) with the language 
set to Essentials of Programming Languages (3rd ed.). 

Our heuristic is sound in that it always returns a specification in programming languages no- 
tation which represents the input dialog, (i.e., it never returns a wrong answer). However, it is 
incomplete in that it does not always return a minimal specification, where a minimal specification 
is one with a minimal number of union operators. If it cannot mine a minimal specification, it 
returns a union of the input set of episodes, each represented as a C expression. For instance, 
line 66 of Listing [3] should display only one expression (i.e., ), but shows two instead (i.e., 

-^U-^). We are performing an evaluation of our heuristic to measure its error rate (i.e., the 

xyzyzx'' f o \7 

fraction of dialog specifications in the universe of possible unsolicited reporting, mixed-initiative 
dialogs U for which it is unable to find a minimal specification in programming languages notation) . 

We can generalize this problem to one of finding a minimum set of posets capturing the require- 
ments of a dialog from an enumerated specification of the dialog. Formally, we state the problem 
as: 

INPUT: A set of poscts P, all defined over the same set, wrhere the union of the linear extensions from each poset in P 
is L. 

OUTPUT: A minimum set of posets R sueh that \R\ ^ \P\ and the union of the linear extensions from each poset of R 
is L. 

We are currently working on an NP-complete proof of this problem using a reduction to Vertex 
Cover. While the dialog mining part of this work is no less important, we focus on staging by 
partial evaluation and stager generation here because it is the aspect of this research most relevant 
to the programming languages community. 

4.2 Stagers 

Note that Tables [9] and [10] only demonstrate how to stage dialogs conforming to each dialog type. 
Here we address how to implement stagers with partial evaluation for dialogs which cannot be 
specified with a single dialog type (e.g., dialog b in Table [6]) or a single expression in programming 
languages notation (e.g., dialog c in Tabled]). 
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One method of implementing (the complete, mixed-initiative) dialog e in Table[6]is to enumerate 
all possible ways to complete the dialog (i.e., all thirteen separate totally ordered sets, one for 
each episode in the specification) as all possible control flows through the implementation. This 
approach quickly becomes unwieldy even for dialogs with only a few questions as we demonstrate by 
capturing the number of episodes in an enumerated complete, mixed-initiative dialog specification 
as a function of the questions posed therein. Let s(m) be the set of all partitions of a set of size 
m into non-empty subsets (where m is a positive integer), and s{m,n) be the set of all partitions 
of a set of size m into exactly n non-empty subsets (where n is a positive integer and n ^ m). 
The Bell number of a set of size m is B{m) = |s(?n)|. The Stirling number of a set of size m is 
S{m,n) = \s{m,n)\. It follows that B{m) = Yl^=i S{m,n). Since an enumerated specification of a 
complete, mixed-initiative dialog contains episodes corresponding to all possible permutations of all 
possible partitions of the set of questions in the dialog, we define its size, \'Dcmi\, as total function, 
N ^ N, equal to Ylp=iP^- ^ ^il^ P)' which given q, the number of questions posed in a dialog, 
computes the total number of episodes therein. Therefore, the number of episodes in a complete, 
mixed-initiative dialog specification explodes combinatorially as the number of questions q in the 
dialog increase. Thus, we seek to obviate the need to extensionally hardcode all possible episodes 
in the control fiow, and thus improve the control complexity of dialog implementation, by using 
partial evaluation to intensionally support such flexibility. 

Consider the stager given in Listing HI This stager, when passed the script shown in Listing [T] 
does not need to anticipate when the user is deviating from the only hardwired episode in the script 
(by virtue of partial evaluation). It does not check that the order of utterances or number of the 
responses in an utterance conform to the dialog specification because all orders and combinations 
are possible. 

While complete, mixed-initiative dialogs can be staged efficiently in this model, such dialogs 
represent only a small fraction of all possible dialogs (i.e., there is only one such dialog, given a 
fixed number of questions). Often there are restrictions on the episodes of a dialog which render 
partial evaluation overkill with respect to its requirements. For example, indiscriminately partially 
evaluating a script such as that shown in Listing [T] to stage dialogs specified by only a C or SPE 
type, such as those in Tables [9l and [TOl respectively, realizes excess episodes (i.e., episodes staged 
which are not in the specification). On the other hand, interpreting (i.e., apply) a script such as 
that shown in Listing [1] to stage a dialog conforming to the PE* type incurs deficit (i.e., some of the 
episodes in the specification are not staged). Using a curried script to stage a dialog specified by 
SPE yields excess and deficit. Thus, while partial evaluation subsumes all other language concepts 
considered here, partial evaluation is an 'all or nothing' proposition [16]. It does not discriminate 
against any of the possible partial assignments of input parameters to the function (i.e., script) 
being partially evaluated (i.e., the script can be partially evaluated with respect to any parameter 
orders and/or combinations). 'For a dialog script parameterized [by] slot [parameters], partial 
evaluation can be used to support all valid possibilities for mixing initiative, but it cannot restrict 
the scope of mixing initiative in any way. In particular this means that, unlike interpretation [or 
currying], partial evaluation cannot enforce any individual [episode]' |16j . 

Thus, to be faithful to a specification, we require a controller to invoke partial evaluation 
judiciously with respect to the different orders and combinations of arguments which reflect the 
requirements (i.e., permissible episodes) of a dialog. We call this controller a stager because it 
stages the interaction required to complete a dialog. A stager must restrict the ways in which 
partial evaluation is applied to a script in all dialogs except those conforming to the PE* type (i.e., 
complete, mixed-initiative dialogs). 

Since staging complete, mixed-initiative dialogs in this model does not require verification of the 
order and form of utterances, the objective of the dialog miner is to identify as much of the input 
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dialog as possible which can be specified through the PE* type. In other words, it needs to identify 
as much of the dialog as possible which can be handled by partial evaluation. This process has 
been referred to as layering |16] . Moreover, the objective of rewrite rules is not to reduce a complex 
dialog to one expressed only through primitives (i.e., types / and C). On the contrary, rather we 
desire to express as much of the dialog as possible through the PE* type to similarly improve the 
implementation. For instance, it is advantageous to express the specification {-<a hy, -<h a,y, -<(a 
b);^} as rather than ^Uj^U^. Furthermore, to take advantage of all possible opportunities 
to use partial evaluation, rewrite rules can be applied not only to the original, pristine, script for 
a dialog, but also to the (transformed and reduced) script remaining after every utterance. For 

instance |mixl[^^,d = ...] = = = and [mixl[^,c = ...] = ^ = |f ■ 

abed cab cab ab a b a b 

This can be thought of as re-layering after every utterance. Unlike Tables [7| and [8l where the script 
to be partial evaluated is the first argument to |mix], here, for purposes of conserving space, we 
use a specification of the dialog in programming languages notation to represent the script to be 
partially evaluated. 



4.3 Evaluation 

One method of quantifying control complexity (or, more specifically, anticipation of permissible 
orders and forms of utterances) is to count the number of expressions in programming languages 
notation a stager for a dialog must support. In other words, the number of expressions required 
to capture the requirements of a dialog is an evaluation metric for the complexity of its stager. 
A complete, mixed-initiative dialog can be captured by one expression. If we remove only one of 
the thirteen episodes from the size bic'r^*cream complete, mixed-initiative dialog, its requirements can 
no longer be captured by one expression. For instance, a dialog where the ^(size blend cream) ;^ 
episode is absent from the ^.^^ bicaM cream specification cannot be represented with less than five ex- 

pressions (i.e., -. — — rr^^ U j-^ U U 7-^, — r)- Therefore, 

^ ^ ' size blend cream size blend cream -, — L — ^ cream r-, — r size -. i blend' ' 

Size blend blend cream size cream 

in this model, a stager for the prior is less complex in the control than one for the latter. While 
size bicM cream represents one poset, note that there is not a one-to-one correspondence between 
posets and expressions in programming languages notation which capture the requirements of a 
dialog. For instance, while the previous dialog cannot be represented with a union of less than five 
expressions in programming languages notation, it can be represented by one poset. 

When the specification for the dialog being staged cannot be captured by a single expression 
(e.g., specifications c and f in Table [6|) we currently require one stager per expression. Then a 
decision, based on the user's first utterance, is required, if possible, to determine which stager to 
invoke. Staging dialogs in the A class which involve sub-dialogs requires additional consideration. 
A stager for these dialogs not only needs to control how partial evaluation is invoked to support the 
individual dialog types, but also needs to coordinate the order in which it jumps into and returns 
from sub-dialogs. 



4.4 Practical Considerations 

We made a few practical considerations in our dialog system implementation. For instance, we 
capture first-class continuations through the call/cc facility in Scheme to restart a stager after 
each progressive partial evaluation. We generate a loop key, which contains a continuation, a script, 
and an occurrence counter, with the initial pristine script. A stager then prompts for and accepts 
an utterance from the user, validates the responses in the utterance and, if valid, marshals it into 
a set of parameter-value pairs, and partially evaluates a script with that set of static parameter 
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Listing 5: Generalized stager algorithm simplified for purposes of presentation. 



(generate-pristine-sub-scripts-f rom-expresslons ) 
(let* ((origin-script (file->list script-f ile-ncime)) 
(origin-counter 1) 
(loop-key 
(call/cc 

(lambda (k) 

(list k origin-script origin-counter)))) 
(loop (car loop-key)) 
(script (cadr loop-key)) 
(counter (caddr loop-key))) 

(prompt-f or-input ) 

(if (valid-input?) 

(if (complete-evaluation?) 

(eval (partially-eval-script-with-utterance)) 
(let ((new-script (similix-script-and-substitute-term))) 
(k (k new-script counter+1)))) 
; ; invalid input 
(k (k script counter)))) 



Figure 3: Stager system design illustrating the central role played by partial evaluation. 

assignments. Finally, the stager generates a new loop key with the specialized script and uses the 
continuation to jump back to the beginning of the stager. The generalized stager algorithm shown 
in Listing [5] illustrates this process. We also incorporate a history-records object, which stores the 
loop key of each stage, to support redo and undo operations. The model of computation supported 
by the functional programming paradigm enabled us to support these finer touches in a simple and 
clean manner, in the spirit of |10j . 

4.5 Stager Generation 

From the set of expressions output by the dialog miner, we automatically generate a stager to realize 
the dialog (see transition from the center to the right of Fig. [2]). Since Scheme is a homoiconic 
language, it is suitable for generating a stager in Scheme. Our stager generator consists of 233 
lines of Scheme code. Given a dialog specified in the programming languages notation presented 
here, it automatically generates a stager, and the necessary scripts, which uses partial evaluation to 
implement the dialog. The size of the stager it generates is dependent on the complexity of the dialog 
to be staged. Each generated stager makes use of a library of helper functions which constitute 196 
lines of Scheme code. The generated stagers must be executed with the scn(^ Scheme interpreter 

^http: //people . csail .mit . edu/jaf f er/SCH| 
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since the Similix partial evaluator [8l[9] which the stagers make use of requires scm. Fig. [3] provides 
an overview of the execution of the dialog system we generate (i.e., the rightmost side of Fig. [2]). 
Our entire dialog modeling toolkit, including the dialog miner and stager generator, is available at 
http : //academic . udayton . edu/SaverioPerugini/ dialog . zip, 

5 Discussion 

The advent and increased use of smart phones as ubiquitous personal computing devices and the 
parallel development of hundred of thousands of app^ provide a new landscape and opportunity to 
research models for designing and implementing flexible human-computer dialogs. The apps whose 
success relies on flexible dialog, including those which involve dialogs for information-seeking and 
-gathering activities, can benefit from a model for designing and implementing dialogs in a more 
systematic and simplified way, especially in reducing time to market. Thus, while this research 
project takes a non-traditional approach to dialog modeling and implementation, we are optimistic 
that it will have an impact on the software development process for smart phone apps where 
flexibility in human-computer dialogs is of paramount importance. Moreover, we feel this model 
has the potential to be widely adopted due to the large, growing, and mutually-reinforcing number 
of apps, application domains, and users of smart phones and similar devices. Prior research projects 
have approached intelligent information system design from a (functional) programming languages 
perspective [101 HI [TJl [15]. However, only a few research projects have sought to marry human- 
computer dialogs with programming languages research [HI [21 [lOl [12]. Thus, we also expect our 
work to generate discussion in the programming languages community. 

5.1 Contributions 

We modified and improved a computational model for mixed-initiative interaction |16l [21 [11] or, in 
other words, a new way to specify and stage mixed-initiative dialogs. The primary theme of this 
approach to identify as many embedded complete, mixed-initiative sub-dialogs in a specification 
since they can be advantageously handled by partial evaluation. Identifying these complete, mixed- 
initiative sub-dialogs permits one to plan for only one episode in a script and judiciously apply 
partial evaluation to it to realize all possible variations of that episode. This non-traditional use 
of partial evaluation makes the dialog flexible without having to explicitly hardcode all supported 
episodes into the control flow of the implementation. We generalized the activity of building a stager 
and, in 233 loc, generate stagers for a variety of unsolicited reporting, mixed-initiative dialogs. We 
feel that we are at a vanguard of a fourth dialog model in the spirit of the three models (i.e., FSAs, 
CFGs, and events) identifled in [5]. We have extended [16^ [2l [TT] in multiple ways. We summarize 
our contributions as, we 

• recognize the need to support multiple orders of responses independent of multiple responses 
per utterance and to bring more structure to the space of unsolicited reported, mixed-initiative 
dialogs. To do so we enriched and augmented a programming languages notation for specifying 
dialogs by adding and modifying dialog types; 

• introduce a dialog mining component, including the layering essential to, and deemed critical 
in [16| for, implementing dialogs containing nested sub-dialogs. Ramakrishnan, Capra, and 

^As of this submission, the number of available iPhone, iPad, and Android apps is estimated to be 360k, 30k, and 
160k, respectively. 
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Perez-Quinones note that developing an initial, optimal representation of a dialog is an open 
research issue in |16j : 

"An interesting research issue is: [g]iven (i) a set of interaction sequences [(referred 
to as episodes here)], and (ii) addressable information (such as arguments and slot 
variables), determine (iii) the smallest program so that every interaction sequence 
can be staged .... [T]his requires algorithms to automatically decompose and 
'layer' interaction sequences into those that are best addressed [by an] interpreter 
and those that can benefit from representation and specialization by [a] partial 
evaluator." [H]; 

Our dialog miner addresses this issue. 

• automatically generate stagers for a variety of unsolicited reporting, mixed-initiative dialogs, 
including those involving sub-dialogs; 

• encompassed all of above in a free, downloadable dialog modeling toolkit. 
5.2 Future Work 

We intend to widen the scope of the unsolicited reporting, mixed-initiative dialogs which can be 
accommodated (i.e., specified and staged) in this model. For instance, we are enhancing our mining 
and layering algorithms so that we can recognize and stage dialogs, involving more than one sub- 
dialog, specified with a SPE in the numerator such as dialog d in Table [6l Since Scheme supports 
first-class and higher-order functions, we intend to explore partially evaluating scripts which, unlike 
that shown in Listing [H accept functions representing scripts for sub-dialogs as parameters rather 
than individual responses. Moreover, we are working on algorithms to deal with dialogs where 
the episodes therein cannot be represented by a single poset (e.g., example c in Fig. [T]). We have 
identified specific examples where a dialog cannot be specified with less than y posets, yet can be 
staged using x scripts, where x < y. We intend to study such cases for insight into solving this 
problem in general. 

Beyond these issues, we intend to lift additional restrictions on the space of unsolicited reporting, 
mixed-initiative dialogs to further expand the space of dialogs on which we work. For example, not 
all dialogs have a consistent number of questions across all episodes. More generally, some dialogs 
have dependencies between responses as identified in [13], in a slightly different context. In the 
dialogs we have presented in this article, due to domain semantics, the answers to the questions 
posed are completely independent of each other. In other words, any answer to any question 
does not disqualify any of the answers to any of the other questions. However, in other domains 
such complete independence may not exist. For example, the 2011 Honda Civic Hybrid is not 
available with a manual transmission and, therefore, there is no need to prompt for transmission 
type once Honda and Civic are specified for make and model, respectively. Therefore, we must 
study how to programmatically represent dependencies between the responses in a dialog. We are 
currently exploring a variety of options to deal with dependencies. In covering a richer assortment 
of unsolicited reporting, mixed-initiative dialogs, we intend to evolve the dialog notation into a 
domain-specific language, and the toolkit into a rapid dialog prototyping tool which dialog designers 
can use to explore and test a variety of unsolicited reporting, mixed-initiative dialogs. 

Nonetheless, communicating independent responses in a variety of orders and combinations are 
practical aspects of common dialogs (as demonstrated in Tabled]). Thus, we feel this approach and 
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project is worthwhile and especially timely when viewed in the context of improving the imple- 
mentation of dialogs within apps for smart phones. Moreover, while the programming languages 
notation presented here is not as expressive as a context-free grammar, we feel that both the philo- 
sophical and conceptual connections between natural and programming languages [l7] suggests 
that additional concepts from programming languages concepts, such as reflection and first-class 
continuations, will find a place in this model. 

We envisage the long-term practical significance and broader impacts of this work involving the 
incorporation of stagers based on partial evaluation into ATM machines, airport or train kiosks, 
smart phones and similar devices, and interactive voice responses systems, since the ubiquity of 
these systems in a variety of service-oriented domains, such as banking, travel, education, and 
health care, provide a landscape for the application of this model. 
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